# Тестирование требований
## Описание
Тестирование требований — это их проверка, чтобы найти ошибки до начала разработки.

Стив <!-- yaspeller ignore:start -->Макконнелл<!-- yaspeller ignore:end --> в книге «Сколько стоит программный проект» пишет, что при разработке требований в продукт вносят порядка 30% ошибок. Часто исправить их на этой стадии гораздо проще и дешевле, чем потом.

## Почему ветка важна?
Для менеджера:
- Увеличивается скорость разработки — меньше одинаковых вопросов к автору требований, меньше переделок после разработки
- Он раньше получает информацию, важную для принятия решений
- Выше качество продукта — некоторые ошибки требований очень дорого или невозможно исправить после разработки

Для автора требований:
- Обратная связь сразу, пока он ещё в контексте задачи
- Дополнительная информация о краевых случаях и рисках
- Меньше одинаковых вопросов

Для разработчика:
- Качественные требования, из которых понятно, что нужно сделать
- Меньше новых требований, которые появляются уже после разработки. И меньше усилий, чтобы вписать их в систему

Для тестировщика:
- Возможность влиять на проект в самом начале. Часто тестировщики знают, как продукт работает на самом деле и какие есть подводные камни
- Меньше багов на этапе тестирования продукта
- Понятнее, что должно получиться и как это проверять. Следовательно проще разрабатывать план тестирования и тестовую документацию

## Что будет, если её не делать?
- Проблемы в требованиях найдут уже тестировщики или пользователи. Чинить такие проблемы может быть дорого, а иногда и невозможно
- Разработчики будут тратить больше времени, пытаясь прояснить детали
- Разработчикам придётся выкручиваться и придумывать костыли, чтобы вписать пропущенные требования в систему

## На кого может быть делегирована?
Аналитики, тестировщики

## Примеры поведения
### Примеры плохого поведения
- Замкнутый круг «У тестировщиков много работы, потому что требования низкого качества → У тестировщиков нет времени на тестирование требований → У тестировщиков много работы, потому что требования низкого качества»
- Новые требования не фиксируются в общем документе, а остаются на словах или в переписках

### Примеры хорошего поведения
- Тестировщики работают с задачей с самого начала — когда обсуждаются и формулируются требования
- Выделяется специальное время, чтобы тестировать требования
- Автор требований оперативно отвечает на вопросы и фиксирует изменения
- Требования пишут и тестируют разные люди

## Способы прокачки
### Практика
В каждом проекте свои требования — где-то это многостраничные документы, а где-то только user story или минимальное описание того, что надо сделать. Поэтому тестирование требований тоже будет разным.

Опирайтесь на критерии качества требований и выбирайте из них те, которые важны для вашего проекта. <!-- yaspeller ignore:start -->Наталья Желнова<!-- yaspeller ignore:end --> в статье [Нефункциональные требования к программному обеспечению.Часть 1](https://habr.com/ru/post/231961) приводит основные характеристики хороших требований:
- Полнота
- Однозначность
- Корректность
- Непротиворечивость
- Необходимость
- Осуществимость
- Проверяемость

Полный список критериев качества требований можно посмотреть в IEEE Std 830-1998.

Автор требований не всегда описывает все необходимое для разработки (например негативные сценарии). Для проверки на полноту требований:
- Проверьте каждый объект по CRUDL (Create, Read, Update, Delete (или Deactivate), List)
- Подумайте о том, что может пойти не так, какие негативные сценарии и граничные условия могут быть. Хорошая техника — составление сценариев использования
- Проверьте, что в сложных условиях «если — то», описаны все варианты. Хорошей помощью может быть таблица решений
- Подумайте о заинтересованных лицах — не забыли ли учесть чьи-то интересы, например спросить техподдержку
- Проверьте, что нет отсылок на неопределённую информацию. Если в требованиях автор пишет «Спроси об этом Машу», то когда дойдёт дело до разработки Маша может быть недоступна

Все участники команды должны понимать требования однозначно. Если у кого-то возникают вопросы — то они могут появиться и у других членов команды. Все, что может быть понятно неправильно, будет понятно неправильно. Обратите внимание на:
- Терминологию — вся команда должна понимать, что стоит за каждым понятием. Одни и те же вещи должны называться одним и тем же понятием
- Качественные определения — «красиво», «удобно», «быстро». Такие требования надо заменять конкретными параметрами, чтобы все понимали как его проверить
- То, что требования написаны простым языком — понятно «кто что делает». Если читателю приходится разбираться со всей мощью русского языка, то сложно понять, что надо сделать

Если требование корректно, то оно не содержит в себе неверной и неточной информации. Этот критерий обычно трудно проверить. Помогает, когда требования тестирует человек, который хорошо разбирается в предметной области.

При проверке непротиворечивости, обратите внимание на:
- Одно и тоже требование написано несколько раз в разных местах — если вы будете его менять, с большой вероятностью где-то забудете
- Союз «и» у требований — это несколько разных требований и они могут противоречить друг другу. Например «быстро, хорошо и дёшево»

Необходимость требования — «а это требование точно нужно?». Это в большей степени работа менеджеров и аналитиков. Но человек, читающий требования, тоже может задать вопрос «Зачем мы это делаем?». Хорошо помогает формат user story.

Когда вы проверяете осуществимость требований, смотрите на то, можно ли это вообще сделать в рамках существующих ограничений. Обычно этим занимаются уже разработчики.

Один из самых важных критериев — проверяемость. Как вы поймёте, что требование реализовано? Как вы поймёте, что проект в целом успешен? Если в требовании нет контрольного примера, либо вы сходу не можете придумать тест — это плохое требование.

Чтобы проверить требования на проверяемость можно разработать набор тестов. Это может быть программа приёмо-сдаточных испытаний, автотесты в TDD, набор тест-кейсов и т. д.

### Консультации
- [Telegram-чат TL Bootcamp](https://tlinks.run/tlbootcamp)

### Теория
#### Статьи
<!-- yaspeller ignore:start -->
- [Виктория Соковикова. Можно ли протестировать техническое задание за полчаса](https://software-testing.ru/library/around-testing/requirements/3356-requirements)
- [Серия записей в блоге про тестирование требований](http://qcthoughtsaloud.blogspot.com/search/label/%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)
- [Вера Данилова. Стратегия тестирования краткосрочного проекта](https://habr.com/ru/company/arcadia/blog/542974/)
- [Анастасия Асеева-Нгуен. 3 Амиго — способ коммуникации для создания качественного продукта](https://habr.com/ru/company/tinkoff/blog/449424/)
- [Анастасия Асеева-Нгуена. Введение в Example Mapping](https://habr.com/ru/company/oleg-bunin/blog/450844/)
- [Darren McMillan. “Wiki” (WWWWWH/KE) requirements testing mnemonic](http://www.bettertesting.co.uk/content/?p=857)
- [Ольга Назина. Чек-лист тестирования требований](https://habr.com/ru/articles/543340/)
<!-- yaspeller ignore:end -->
#### Видео
<!-- yaspeller ignore:start -->
- [Дарья Теплова. Тестирование требований, когда требований нет](https://www.youtube.com/watch?v=d380GC7VQJY&t=1866s)
- [Сергей Мартыненко. Написание тестов как вид тестирования требований](https://vimeo.com/13803733)
- [Юлия Нечаева. Как тестировать требования](https://vimeo.com/13804386)
- [Анастасия Асеева-Нгуен. Тестовое покрытие по Бейзеру](https://www.youtube.com/watch?v=jqjJ256CZhk)
<!-- yaspeller ignore:end -->
